An important part of the business of a telecommunication company or organisation is in the provision of services other than simply providing dialled voice connections between users. Examples of such services are voice mail, conference calls, information services and so on.
Conventionally, the programs to provide such services herein referred to as “service applications” are written in compiled languages, such as Java or C++. A large proportion of the existing or legacy software providing such services is in such a compiled form and has the benefits that it has been optimised and is generally reliable. The disadvantage is that such compiled service applications are static, dint is their structure and code are well established, and the programs are difficult to adapt or customise.
To provide easily customised services, interpreted scripting languages have been developed which ease the authoring of new services or providing customisation of services. Examples of these are the Voice Extendible Mark-up Language (“Voice XML” or “VXML”) SALT or variants thereof which will in this specification be referred to generally as “voice mark-up languages”. The voice mark-up languages are interpreted languages similar in structure to HTML. A script written in a voice mark-up language comprises a series of instructions or tags which are interpreted and acted on in sequence by an interpreter. The interpreter is able to receive input in the form of speech and generate an audible output whether in the form of speech generation from text or in the form of saved audio files or otherwise. Appropriate commands in a voice mark-up language also permit the script to accept inputs in the form of DTMF tones from a telephone. A service application written using a voice mark-up language may be in the form of a plurality of pages, analogous to a set of HTML pages made available over the World Wide Web where each page is identified by a uniform resource locator (“URL”).
An appropriate computer system for providing a plurality of services, hereinafter referred to as a telecommunication service platform, of known type is shown in FIG. 1. Referring now to FIG. 1, a telecommunication service platform is shown generally at 10. The telecommunication service platform 10 has a plurality of layers. Starting from the top, a service layer is shown at 11. This generally includes all the programs or service applications which provide services running on the platform 10 including interpreters and service wrappers where appropriate. The service layer is supported by the session layer 12, which manages calls connected to individual services, that is it allocates and manages the resources needed to provide the required service for a call. The communication layer 13 gives access to network, media and system resources. In this example, the communication layer 13 has a media processing layer 13a which provides media resources to the service layer 11 and a signalling layer 13b which gives access to the network and system resources needed to control calls at a network level. For simplicity, in this example the communication layer 13 comprises the various protocol stacks. At 14, the hardware layer is shown including the physical component necessary to provide the voice connection channels 14a and signalling channels generally shown at 14b to receive and establish calls over a telecommunication network.
The session layer 12 itself has two layers. As shown at 15, an appropriate interface is provided, preferably in the form of an open application programming interface (“API”). The API provides a set of functions which may be called or invoked by a service application in a way which is independent of the underlying network protocol and hardware. A media controller 16a provides control of the media resources available through the media processing layer 13a A platform framework or call controller shown at 16b performs the necessary scheduling, resource and session management function between the interface 15 and the communication layer 13.
In the service layer 11, a number of different types of service applications to provide services are illustrated. At 17, a voice mark-up language interpreter is shown operable to read service applications 18, 19 which are implemented as voice mark-up language scripts. At 20 and 21, compiled applications are illustrated which are able to communicate directly with the interface 15. At 22, a non-native application is shown, for example a service application written in a language not directly compatible with the interface 15, which is provided with a service wrapper 23, for example an API adapter, to adapt messages transmitted between the interface 15 and the application 22 into an appropriate format.
To provide adaptable and efficient services, it is desirable that applications of different types be able to interact. Voice mark-up language-implemented services are desirable in that they provide easily authored and adapted service applications but have disadvantages in that the language does not permit a very sophisticated logic and large grammar or numbers of grammars to be known for a given application, where the term “grammar” refers to the set of allowed (and thus identifiable) words. The relatively unsophisticated logic also does not allow the interpreter to make assumptions about what the interaction steps will be. For example, in a voice mail service, it might be assumed that the user will wish to listen to new messages whilst being connected to the service and so new messages could be uploaded in advance to be ready to be played while receiving the appropriate instructions; this is relatively straight forward to implement in a compiled service application, but cannot easily be done with a service application written in voice mark-up language. As discussed above, a quantity of optimised reliable legacy software exists in compiled form, and it would be desirable to be able to use such compiled service applications in conjunction with service applications written using a mark-up language.
It is known to transfer calls between compiled service applications by making an appropriate call to the API 15, for example using the method ReleasedToService method in the Java Telephony Application Programming Interface (“JTAPT”) Media application. Such a call is not however accessible by a voice mark-up language script. It is possible to call other mark-up language applications, from a script for example using the <subdialog> or <link> tags in VXML, or to transfer a call using the <transfer> tag which causes a call to be redirected to another number or application indicated by a URL at the network level.
An aim of the present invention is thus to permit easier interaction between voice markup language service applications and compiled service applications.